home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0020.txt < prev    next >
Text File  |  1987-11-12  |  7KB  |  177 lines
  1. FSC-0020
  2.  
  3.                      Alternate Nodelist Flag Proposal
  4.  
  5.                            by Marshall Presnell
  6.                               (109/639.106)
  7.  
  8.                             November 13, 1987
  9.                                      
  10.        Permission  to  reprint  and  distribute  this  document is 
  11.        granted so long as no payments are incurred for the use and 
  12.        distribution of this document and the author is credited.
  13.  
  14.        $Revision:   1.1  $
  15.  
  16.        $Log:   E:/SRC/NLPROC/PROJFILE/NODELIST.PRV  $
  17.    
  18.       Rev 1.1   13 Nov 1987 15:50:56   M. Presnell
  19.    Added Update log into document body
  20.  
  21.        ------------------------------------------------------------
  22.        
  23.                               NODELIST FLAGS
  24.                                 A Proposal
  25.  
  26.        In order  to properly  code a function to read and interpret
  27.        the nodelist  flags, several vexing problems arise. The most
  28.        significant problem  is simply figuring out the capabilities
  29.        of the  software running  at a  particular node. In order to
  30.        solve this  confusion, I  propose the following standards to
  31.        be accepted  by the  FTSC, IFNA,  and  any  other  anciliary
  32.        organizations  which   contribute   to   the   content   and
  33.        maintenance of the nodelist.
  34.        
  35.        First, a  code needs  to be  established for  each piece  of
  36.        NETMAIL PROTOCOL CAPABLE software. This defines exactly WHAT
  37.        will answer  the phone  and transfer  mail according to FTSC
  38.        netmail  protocol   standards.  For  the  current  arena  of
  39.        software,  I  propose  the  flag  and  operand  approach  as
  40.        follows:
  41.        
  42.             ST: <- the FLAG, ST meaning System Type
  43.        
  44.             Operands:
  45.        
  46.             FD1 - Fido Version 11?
  47.             FD2 - Fido Version 12?
  48.             SD? - SEAdog version ?
  49.             OP1 - Opus version 1.?
  50.             BT? - BinkleyTerm version ?
  51.             TY? - Tabby version ?
  52.             DT? - Dutchie version ?
  53.             (and others as needed, apologies to those I omitted)
  54.        
  55.             Therefore, the complete type flag would read:
  56.        
  57.                  ST:FD2 for Fido v12x
  58.                  ST:OP1 for Opus version 1.xx
  59.                  ST:SD4 for SEAdog version 4.x
  60.        
  61.             This  gives the nodelist processor (and we illogical
  62.             humans)  a  much  easier  time  in  interpreting the
  63.             nodelist. I also recommend that the operands be of a
  64.             set length (in the above example, 3 characters).
  65.        
  66.        Second, a  PROTOCOL code  needs to be established, using the
  67.        same FLAG:OPERAND  approach as the system type flag. In this
  68.        case:
  69.        
  70.             PR: <- The FLAG, meaning PRotocol
  71.        
  72.             and the operands:
  73.        
  74.             TS - TSYNC          (Fido v11 and v12)
  75.             SL - SEAdog Link    (SEAdog)
  76.             WZ - WaZoo          (Opus)
  77.             others as the technology progresses.
  78.        
  79.             The operand field may contain multiple operands, as
  80.             follows:
  81.        
  82.             PR:WZ/TS <- to indicate an Opus system
  83.        
  84.             In  the  event  of multiple operands, the most desired
  85.             protocol for network communications should be first in
  86.             the list of operands.
  87.        
  88.        Third, the  operation hours,  as before  in  a  FLAG:OPERAND
  89.        combination as follows:
  90.        
  91.             OH: <- Operation Hours
  92.        
  93.             This  flag  is  followed  by the operation hours of the
  94.             system regarding inbound MAIL only. The operation hours
  95.             are in a fixed format as follows:
  96.        
  97.                  D.HHMM-D.HHMM
  98.        
  99.             where  D  is the day number (Sunday being 1), HH is the
  100.             24 hour military  hour, and MM is the minute. A special
  101.             case of the day being 0 means all days 1 through 7. ALL
  102.             times are EST (purely  arbitrary,  but ALL times in the
  103.             nodelist  should  have  a  common base reference time).
  104.             Therefore, a system which runs national  mail time only
  105.             would be as follows:
  106.        
  107.                  OH:0.0400-0.0500
  108.        
  109.             Multiple  operational  hours  may  be  specified  by
  110.             separating the separate time specifiers with a slash
  111.             as follows:
  112.        
  113.                  OH:D.HHMM-D.HHMM/D.HHMM-D.HHMM/D.HHMM-D.HHMM
  114.        
  115.             Continuous inbound mail would be indicated as follows:
  116.        
  117.                  OH:1.0000-7.2359
  118.        
  119.             It is important to note that these times are when the
  120.             system  is  able  to  RECEIVE mail. These are NOT the
  121.             actual operation  hours  of the BBS (if one exists at
  122.             that node).
  123.        
  124.             The  time known as National Mail Hour (04:00 to 05:00
  125.             EST)  is  automatically   ASSUMED  and  need  not  be
  126.             incorporated into the FLAGS field. Since it is one of
  127.             the  baseline  requirements  for  being listed in the
  128.             nodelist, this assumption is a relatively safe one.
  129.        
  130.             Also,  this method should also be used to indicate the
  131.             time(s) when File Requests are accepted. The suggested
  132.             flag for  File  Requests is "FR:" and follows the same
  133.             time specification logic as the OH: flag.
  134.        
  135.        Fourth, modem flags need  to  be  standardized  (until  the
  136.        modems themselves can be  standardized),  for  a  hopefully
  137.        "stop gap" measure, we could use the following:
  138.        
  139.             MDM: for the flag,
  140.        
  141.             TLB for Telebit Trailblazer
  142.             HST for USR Courier HST
  143.             H96 for Hayes 9600
  144.             (and others as needed)
  145.        
  146.             Only ONE of these modem types can appear per node, and
  147.             it has  no  relavence  unless the baud rate is greater
  148.             than or equal to 9600.
  149.        
  150.             (This is one of those flags we can get rid of once the
  151.             modem manufacturors establish a standard.)
  152.        
  153.        Fifth, the  Mail Only flag. Basically, it need to be changed
  154.        to "#MO"  instead of  "MO:". All  flags which  do  not  have
  155.        operands should not contain the colon (:) character.
  156.        
  157.        Flags occur  following the  seventh comma in a nodelist line
  158.        and continue  to the end of the physical line. All flags and
  159.        flag:operand combinations  are separated by commas, with the
  160.        last flag  on  the  line  terminated  by  the  end  of  line
  161.        character. Order of the flags is not critical.
  162.        
  163.        ------------------------------------------------------------
  164.        
  165.        I hope this proposal will serve to elicit ideas and comment.
  166.        Please direct any inaccuracies, suggestions for improvement,
  167.        comments,  and  constructive criticism to  Marshall Presnell
  168.        at Fido node 109/639.106
  169.        
  170.        Thank you.
  171.     
  172.  
  173.  
  174.  
  175.  
  176.  
  177.